During the execution or running of an application, a multitude of events may take place. For example, the application may execute multiple steps multiple times. The application may run loops in multiple iterations. It may make and close numerous connections. Threads may be initiated and completed. An event may trigger other events, which may trigger still other events. Prior to execution of such events, an execution plan may be developed showing how the execution of the events will be completed.
An application or an event in an application may generate log events or a historical record of events occurring during the running of an application. After the execution plan is developed but before it is executed, it also may be logged. For troubleshooting purposes, a user may benefit from reviewing the application's logged events. A user may further benefit from viewing information about any of the events that occurred during the execution of an application. Such information may aid in diagnosing problems or answering questions related to results of the execution of the application.
When an event is to be executed, a decision may be made to create a log or not to create a log. That is, a choice may be provided to either log or to not log an event. If the event is to be logged, then information regarding the execution of the event may be sent to a log. Aside from being able to turn logging on or off, little flexibility may be included in the logging technique.
Typically, a logging event may be flat in the sense that all of the log event information may be sent to a single destination. Upon execution of an event, the event information may be logged without any segmenting of the information to retain, for example, desired information and delete undesired information. Instead, all of the event information may be logged. A user then may filter all of the logged events for viewing. That is, the user may view the information in which the user is interested but may not be able to select the event information to be logged. Additionally, some logging may include a filtering of the information before delivery to a single destination. Other logging may include logging to multiple destinations but may not include filtering. Logging options may not include the ability to send a piece of information related to a log event to one destination, and another piece to another destination.
As noted, typically, the event log or logs later may be searched depending on information desired. However, because information is logged and then filtered for viewing purposes, the log may provide information regarding only critical or essential events. System constraints or memory limitations may limit the logging of both critical and less critical events. For example, logging may not record data relating to an execution plan. A choice of only to log or not to log may not enable a user to selectively log a particular kind of event. Additionally, a user may not be able to send part of a log event to one destination and another part of the event to a second destination, even though certain events may be of interest to specific users but not to other users. The typical logging options may not enable a logging event to be selectively delivered to a user who may be interested in the event and to not be delivered to another user who may uninterested in the event.
Therefore, there is a need to enable a user to exercise a fine degree of control over the large volume and different types of logging information regarding execution plans, event executions, and other occurrences within an application. There is a need for a system enabling a log event to be disseminated to multiple destinations and to enable segmenting the log event such that part of the information may be sent to one destination and another part to a second destination. There is a need to enable a user to control logging configurations, log filtering, scope of logging, destination designations, and log formats.